If you do not hear the dial tone or the touch tones as the modem dials, then either you have a modem without a speaker, your modem is not connected to the phone line, your cable is not working, or your modem is not plugged in. Check all of these again.
No response
If you connect and nothing at all happens, I suggest you type another carriage return. This may wake up the bulletin board system. If this does not work, try hitting the <esc> key a few times. This key is located in the upper left corner of your keyboard. If this doesn’t work, try selecting Send Break from the Misc menu.
 
Chock full o’noise
Another thing that can go wrong is that you can get a very noisy phone connection. In this case, your session may look something like this:
CONNECT 2400 BMUG 2400 bps
ñW$≠].]êconnected to Akbar & Jeff's Noise Hut, ALAS....
BMUG Online Jy≤QUØ Ë∆íÿßd(SM). All Wron{}(*gs∆í&% Deserved. All private messages on
this BBS arJy≤Qÿßde read by the Exe{utive Director of BMUG,
Steven Jy≤$≠] Ë∆íñWdW Costa, andJy≤YQ$≠]∆íÿPd the Chairman of the Board, Gregory Dow. Every last one of them!
The best thing to do under these circumstances is to hang up by selecting Hang Up from the Dial menu and either call from another phone or try again later.
 
Hardware Handshaking
Hardware handshaking problems are one of the most common, and difficult problems that beginners run into. They are insidious because they often only show up during file transfers, when it is difficult to diagnose the source of the problem.
The problem is most common among recent purchasers of high speed modems. After picking up a “standard” modem cable at a nearby store, the neophyte brings their brand new modem home. Filled with fantasies about attaining transfer rates in the stratosphere, they set their communication program to 56 kbps and dial up their favorite BBS to take their new toy “for a spin.” Alas, not only does the modem not perform as advertised, but they find that ZMODEM transfers which were fine at 2400 bps now abort due to an excessive number of errors. Angry that their new toy doesn’t work, the neophyte now writes a nasty letter to the Sysop, telling them to fix their defective ZMODEM implementation.
What’s wrong with this picture? The neophyte’s problems are not due to the BBS, or their modem, but rather due to their communications settings, and the type of modem cable they are using.
Firstly, the “standard” cable that the neophyte purchased probably doesn’t support hardware handshaking, which is advised when communicating at speeds of 9600 bps and above. Since most computer stores don’t stock hardware handshake cables, and wouldn’t know such a cable if they saw one anyway, the thing to do is to get the cable right from the manufacturer (Supra offers a kit with the cable included) or from a specialty cable outfit, such as Celestin Company.
Secondly, the neophyte’s communications program probably isn’t set to do hardware handshaking. Here’s what the ZTerm dialog box for hardware handshaking looks like. You can get to it by selecting Connection... from the Settings menu. Notice that I have both Hardware Handshaking and XON/XOFF selected.
 
What is the source of the problem? If it occurs during an upload, then the neophyte has been forcing the computer to send data to the modem at 56 kbps, which is faster than it can receive it on a sustained basis. If the problem occurs during a download, then the neophyte has been forcing the computer to receive data from the modem at 56 kbps, without the ability to pause if it is interrupted by other events, such as another application running in the background, or the need to write a buffer to disk.
Without hardware handshaking, there is no way for the modem or computer to temporarily stop the transfer when they are overloaded. As a result, the modem or computer’s internal buffer can overflow, losing data. The result is that received or sent packets contain invalid data, resulting in a “CRC error” message. Eventually the file transfer aborts due to too many errors.
Why can’t a V.32bis/V.42bis modem (often advertised as having a maximum transfer speed of 38.4 kbps or 56 kbps) actually send data at this speed? The problem is that the marketing types at the modem vendors have been pulling a fast one. In reality the V.4bis compression that marketing types get so excited about contributes nothing when users download compressed files, as they do almost all the time. Therefore the neophyte’s modem is only operating at its maximum modulation speed at best, and probably slower due to line noise. In the case of
V.32bis modems, the maximum speed is 14,400 bps. Therefore a speed of 19,200 bps would suffice to drive the modem at its maximum rate.
Why can’t a V.32bis/V.42bis modem (often advertised as having a maximum transfer speed of 38.4 kbps or 56 kbps) actually send data at this speed? The problem is that the marketing types at the modem vendors have been pulling a fast one. In reality the V.4bis compression that marketing types get so excited about contributes nothing when users download compressed files, as they do almost all the time. Therefore the neophyte’s modem is only operating at its maximum modulation speed at best, and probably slower due to line noise. In the case of
V.32bis modems, the maximum speed is 14,400 bps. Therefore a speed of 19,200 bps should suffice to drive your modem at its maximum rate.
If the file you are transferring is uncompressed, V.42bis might actually be able to speed the transfer somewhat, and if the on-the-fly compression is more than 25%, the modem might actually be held back by only being fed at 19,200 bps. This is why many “experts” recommend setting the speed to 38,400 kbps instead, to insure that your modem will operate at its maximum possible transfer rate under all conditions. However, my own tests indicate that going from 19,200 bps to 38,400 bps is rarely beneficial, and can actually result in lower transfer rates on occasion.
Wrong Speed
Yet another possibility is that you might connect to your chosen system at the wrong speed. This could happen if you have a 1200 bps modem, because the default settings in ZTerm are for 2400 bps modems. In this case, your session may look something like this:
Äx˛¯¯x˛¯x‡Äxį¯x‡Ä¯ÄÄx Äx x ¯xx‡Äx˛Äx¯Äx ¿¯x Äx‡¯x Äx‡¯¯Ä¯x įx˛¯x˛Ä¯¯x xx‡Äxx‡¯¯Ä
xįx¯x Äxįx¯x x <<‡x ¯x x‡¯¯Ä¯¯x‡Äxįx¯¯x ¸xÄÄx˛¯x x‡Ä¯Äxx‡Ä¯x‡Äx į¯Äx˛¯x‡Äx ¸x
Artistic, right? To fix this, select Connection... on the Settings menu. You will then
be greeted with the communications dialog box:
 
Change the Data Rate to match the number after the word CONNECT (above). As the menu shows, my 2400 bps modem had been set at 9600 bps while dialing another 2400 bps modem.
 
Skip this section – Arcane discussion of flow control ahead
Back in the section on Hardware Handshaking, the modem heads among you may have wondered: why use two methods of flow control, XON/XOFF and Hardware Handshake?
XON/XOFF is an end-to-end flow control mechanism; that is, it controls flow between two pieces of software. In order for this to work, both applications must agree to the XON/XOFF convention. In this convention, an XOFF character (cntrl-Q) turns off flow, and an XON character (cntrl-S) turns it on again. XON/XOFF is only one convention for end-to-end flow control; upper level protocols (such as TCP/IP) may contain their own end-to-end flow control mechanisms. In the case of TCP/IP, flow control is maintained by a mechanism called window advertisement, in which the receiving system advertises the size of the sliding window that it is prepared to accept.
The important thing to understand is that use of end-to-end flow control does not decrease the need for flow control at lower levels, such as at the computer/modem or modem/modem level. Within TCP/IP for example, not only is there an end-to-end flow control mechanism (window advertisement), but there is also a mechanism by which an overloaded node on the network can tell a sending node (which may not be the originator of the packets) to slow down. This is known as Source Quench.
Hardware Handshaking functions as the low-level flow control mechanism between a computer and an attached modem. There is also another low-level flow control mechanism, that operates between the two modems. This mechanism is part of the V.42 standard.
Why do we need Hardware Handshaking? At speeds of 9600 bps and up, it is possible for the computer to send bytes to the modem, or for the modem to send bytes to the computer so quickly that the buffers on the computer or modem will overflow. When this condition is approached, there needs to be a way of sending a signal to stop the flow.
That signal cannot easily be delivered as a sequence of bytes. Think about it: if the computer could stop the modem by sending it a string of bytes, what would happen if that string was sent by accident as part of a file transfer? The transfer would abort, because the modem would stop, and the computer wouldn’t know why. Therefore, the signal is sent electrically, using the hardware handshaking lines that run between the modem and the computer.
There is one line (CTS) with which the modem tells the computer that it is ok
to send; in Macintosh lingo this is called Handshake In. Another line (RTS) is used by the computer to tell the modem that it is ready to receive. In Macintosh lingo, this is known as Handshake Out. If the computer’s receive buffer is full, it “negates” RTS; if the buffer the modem uses for incoming traffic from the computer is full, it “negates” CTS.
What other buffers are there? Well, modems also have buffers to manage bytes coming and going between each other. These buffers (which are smaller than the computer/modem buffer) must also be managed. This is accomplished via the flow control mechanisms available in error correction protocol such as V.42. This flow control mechanism is brought into play after a computer signals to the modem that it cannot accept any more data, by negating the RTS line. In order to keep its modem/modem buffer from overflowing, the attached modem must therefore signal to the other modem to stop sending. The other modem in turn then negates its CTS line, signalling to its attached computer that it is not ready to accept data.
How do the modems handle flow control between each other? Under the V.42 protocol, the receiving modem can send a Receiver Not Ready (RNR) frame to the sending modem to tell it to stop. Another mechanism is to not acknowledge the incoming packets. However, this will not work beyond when the retransmission timer expires. V.42 is a sliding windows protocol with a window size of 15 frames, and a sequence number modulus default of 128.
